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(54) Method for wide area network service location 



(57) A method for a client to locate a particular serv- 
ice from a service provder on wide area computer net- 
works. The method includes multicasting of an adver- 
tisement from a service provder. when advertisement 



is detected by a Service Broker and in turn multicast into 
the wide area computer network. A ciient quenes the 
network when seeking a particular service ana receives 
m turn the address of the Sroker and a Server to ootatn 
the service desired. 
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Description 

Re*d of the Invention 

The instant invention relates to the general problem 
of service location m wide area computer networks and, 
more particularly, to the specific problem whtch arises 
wnen a user wishes to locate some service, such as a 
mecia bnage. internet teleohony gateway, H.323 Gate- 
keeper, jntcast to multicast bridge, etc. , which has some 
desired characteristics, but wnose location (in terms of 
network acdress. domain or geographical location) is 
completely un*nown and may be anywnere on the pub- 
lic network. 

Background of the Invention 

Today, there exsts a number of examples of wide 
area services. One is media bndges, when are devices 
used lor mixing voce or video together for multipoint 
conferences. Another might be a media server, which 
contains movies and multimedia accessible to the user 
for playback. Another example are Internet telephone 
gateways. These devices allow Internet hosts to com- 
municate with standard 'POTS* telephone users by 
translating internet telephony to traditional telephony. 
Yet another example is a multicast to uncast bridge, 
which would allow unicast-onry endpoints to receive 
multicast. 

Generally, with currently existing technology, serv- 
ice location mechanisms need to be involved for every 
call set-up. This makes their location a time critical, and 
ootentiaJry network and CPU intensive operation. Fur- 
thermore, relaying internet teleohony calls to the PSTN 
results n cost for the gateway provcJer which must 
somehow be passed on to the remote user. This also 
requires security mechanisms to provide authentifica- 
tion ana authenticity in an international environment. 

Prior art systems and devices exist for locating serv- 
ices, but none work well for wtde area network service 
iccat on Por example, some pnor art pubScaoons have 
taugnt the use of DNS records for finding services in a 
particular oomain. See for example A. Guferancsen. P. 
vixie 'A DNS RP for Specifying the Location of Services 
DNS SflvV. !£TP Request tor Comments 2052. Octo- 
oer 1996. and R. Moats. M. Mammon. P. Leach. 'Finding 
StufT IETF intemetOrafl draft-*etf-srvtoc-diecovery- 
•32.00. Work n progress. Poor art puolicauons have also 
addressed the problem of finding fax gateways in a par- 
ticular telephone exchange: see. for example. C. Mata- 
mud. M Rose. 'Principles of Operaton tor TPC INT 
SuOdomejn: General Ponapm and PoUcy 0 , IETF Re- 
sue si for Comments 1530 October 1993 

~he use of DNS require* the client to know the do- 
Tian name wtiere the server is located, when is gener- 
ally not oossiOte The Service Location Protocol see for 
examote. - Veizaces £ Gunman C 3 erkins. S <ao- 
an Service Location Protocol*, i ETF Peouest for Com- 



ments 2165. June 1997, ts used for location of services 
in an administrative oomain, but does not work for wide 
area networks as it ends up using excessive bandwidth 
as more servers and clients use it. The Session An- 

5 nouncement Protocol (SAP). M. Handley. 'SAP - Ses- 
sion Announcement Protocol', IETF internet Draft, 
Work in Progress, allows for announcement of services, 
but requires an excessive amount of time for clients to 
learn about them. Web search engines, such as Lycos 

10 and Alta Vista, can also be used for the location of serv- 
ices. However, sucn search engines tend to generate 
excessive traffic, and service location control rests n the 
hands of a few. dedicated search facilities. This has iim- 
ited scalability. 

15 It is, therefore, an object of the instant invention to 
provide a solution to tne service location prooiem wmcn 
is efficient and scalable both m use ot canewctn and 
CPU power. 

It is a further object of the instant invention to pro- 
20 vide a protocol arch lecture wnich allows clients n a data 
network to readily locate services tn a wide area net- 
work. 

It is another object of the instant invention to provide 
a protocol architecture wnich scales to an infinite 
25 number of clients and millions ol servers without requir- 
ing excessive bandwidths. while at the same time being 
fast, simple and flexible. 

Summary of the Invention 

00 

The claimed invention comonses a protocol archi- 
tecture which allows clients connected to a data n etwork 
to locate services in a wide area network such as the 
internet. The invention scales to an infinite number of 

3S clients and millions of servers without requiring exces- 
sive bancwidths and is also fast, simcie anc flexible. 

The inventive method includes activating a server 
X to provide a service A to clients ana when activated 
server A broadcasts an advertisement for service A to 

•to a multicast group 

Broker Y stores the advertisement for service A in 
its database and broadcasts the advertisement tor serv- 
ice A to a multicast group G 2 . when aaventsement is 
detected by Directory Agent Z ana storeo m ?s aaia 

<*£ base. 

A client looking to fina a server tor service A queries 
Directory Agent Z and receives the address tor 3roker 
Y, wno (hen provides to the c:ieni the aooress fcr server 
X 

so The cient is then able to contact server X to cotan 
service K 

Brkf O— crlption of Drawing* 

ss Xhm invention is pointed out with oartcuianty m me 
appenced claims. The above and further advantages of 
mis inventon may be better understood oy reternng to 
the foilowng cescroiton lanen »n conjunction *ttn tne 
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acco mpan ying drawings in which: 

FIG. 1 is a diagram of the protocol architecture of 
the Instant invention allowing clients m a data net- 
work to locate services in the wide area network; s 
and 

FIG. 2 describes the flow of events whch occurs 
when the system protocol architecture is initialized. 



Detailed Description of the Invention 
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We formally define the wide area service location • 
problem as follows. A client on a computer network (IP 
based, ATM, etc.) wishes to find a server that provides 
a sen/ice. There are no restrictions on the name space. *s 
network acdress space, geographical location, or ad- 
ministrative domain where the server may be located. 
Furthermore, the client has no knowledge of the location 
of the server. It has only a definition of specific annbutes 
or constraints (e.g., supported protocols, type of billing 20 
used, cost) which are desirable or metrics to minimize 
or maximize (e.g.. cost, quality, distance). A protocol is 
needed to allow the client to find the server The require- 
ments for such a protocol are: 

2S 

1 . Scalable: The protocol should work for many cli- 
ents and servers, without using excessive network 
bandwKJth, and without requiring too much time to 
locate the service 

2. Allow for costs Network servers may charge for 30 
their services. The protocol should allow a client to 
choose a server based on cost minimization. 

3. Allow for distance: A client may require a server 
to be close to ft. in order to minimize network delays. 

it should be possible to locate a server based on its 3$ 
proximity to the client. 

4. Support authentification: A client my want to 
know that a server is really trustworthy. Mecha- 
nisms must exist for authentcatng and verrfy ing the 
services provtied by a server. «*o 

The inventive arch*ecture for the instant invention 
whch fulfills these requirements s snown tn FIG. 1 . The 
various components of the architecture are Germed as 
toitows: 

Referring first tc tne Servers A-0 shown m F!G. 1 . 
they advertise usng network multicast m order to let cli- 
ents use their services. To do sc. they send messages 
into a mutt cast group, oescrtotng the attnbutes and cost 
structure of the services they provide. so 

For each service, a plurality ot multicast addresses 
are defined These are computeo as a stnng hasn of the 
service Service Brokers (Shown m FIG. 1) listen to this 
multicast address, in addition, any Server wisnrg to ad- 
vertise this service also listens to this address. 3y lis- ss 
tenmg to this address a Server wishing to aoventse on 
•t can keeo track ot the numoer of other Servers also 
advertising 



When using multicast to distribute information 
about services, some kind of control must be exerted to 
limit the frequency of advertisements from a server. If 
the frequency were fixed, the total number of packets 
sent to the multicast group, and received at each broker 
(defined below), would grow linearly with the numcer of 
servers advertising. This can iead to congestion ana 
poor performance. To oeal with this, the frequency of the 
advertisements from a server is set to scale oack based 
on a simple technique. 

Any server whch advertises to a multicast group G 
also joins and listens to the group, ft counts ;he number 
of distinct other servers which send advertisements :o 
the group. Let's say N other servers are heard from The 
period of advertisements from the server is then set to 
N times some basic pence Tb. This iimits tne total 
amount of bandwidth on a multicast group to roughly 
one packet every Tb seconds. This is independent of 
the number of servers advertising. The Danawicrth us- 
age thus scales well, at the expense of less frequent 
advertisements. 

Some additional asoects of this basic 'tacK-off al- 
gorithm can also be used. 

1 . The period is always made greater than some 
minimum 

2. The minimum period increases with the age of 
the advertisement. The age is defined as the 
number of times the exact same advertisement nas 
already been sent When any parameter of the ad- 
vertisement changes, the age is reset to zero. This 
allows older advertisements to be sent iess fre- 
quently. 

3. A random factor is added so that the actual period 
vanes randomly between 1/2 and 3/2 of wnatever 
the deterministic period, computed above, turns out 
to be. The random factor neios avoid some synchro- 
nization pathologies that can occur. 

Lets say a Server hears N other servers We define 
a parameter CONFIG JNTERVAL_i 2. whicn ;s the av- 
erage worst <ase interval of 1 koyte packets :o be trans- 
mitted, summed across all servers. ;nto the multicast 
group. Each Server wishrg to sena an advertisement 
of size < will periodically sena the advertisement wiin a 
period T equal to: 

TsH(l/2VnaxtCONFIGjNTERVALj3*Fiagei. 
NXONFIGJNTERVAL_12*K/102 4 V 

where 

F(age) >s a function when starts at some fractional 
power of two. 2*< -CONFIG JNTErVAL. 1 *) wnerever , 
an advertisement is different irom tne previous. For 
each suoseouont advertisemeri whicn <s net artferent 
from the previous. F(age» oouoies. until <t ^ns * ana 
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then it stays fixed at 1 We also define R( 1/2) as a ran- 
dom variable uniform ry distributed between 1 /2 and 3/2. 
Fef example, say that CONRGJNTERVAC.12 a 64ms. 
TTrttf means that the total rate of packets sent into the 
group will be 128 kbps when group sizes are large, if 
there are 1000 servers, each sending 1 kSyte packets, 
each one will get to advertise once a minute. When 
group sizes are smaller, the packet rate remains at 1/ 
CONFI G J NTERVAL_1 3 (perhaps 32 kbps) during 
steady state. However, when an advertisement chang- 
es, the rate can temporarily increase (but not above 
I28kpbs) to hasten the broadcast of this announce- 
ment. 

This mechanism allows for the number of Servers 
to grow without causing an increase in the bandwidth 
used on the multicast address. A similar mechanism is 
used in RTP to provtde scalability, (described by J. 
Rosenberg and H. Schulzrinne, in Timer Reconsidera- 
tion For Enhanced RTP Scalability*, proceedings of the 
IEEE. Infccom *98. The advantage of this approach is 
to solve two of the limitations of the prior art. First, Serv- 
ers do not need to know the actuai addresses of Bro- 
kers. This eliminates the need for wide-area multicast 
searches and/or Broker advertisements (used in the 
Service Location Protocol). It also makes the system dy- 
namic. As soon as a new Broker is turned on. it can in> 
mediately learn about new servcee t and this process is 
transparent to the servers providing the service (this is 
not the case for the web search engines, for example), 
it also solves the problems of excessive load on brokers. 
The rate is now finely controlled, independent of the 
number of Servers. 

Servers that are not multicast capable, or which do 
not want to subscribe to the service advertisement mul- 
ticast group for reasons of bandwidth or complexity may 
use Notary to diffuse their service aoVertisements as de- 
scribed oelow 

Turning now to a Servee Broker (shown in FIG. 1 J, 
this element of the arch lecture accepts service re- 
quests and service type requests from clients. These re- 
quests ask for me location of a Server matching a set of 
cntena desenbed by the cttent The Broker answers with 
service replies and service type replies. A Broker gen- 
erally nancies service requests tor one or several spe- 
cific services: that ts why it is called a Service 3roker. 
This is required « order to scale the disk storage and 
processing requirements for Brokers, it is also desirable 
since different servcee may have different requirements 
for rmtchng client requests. For example, the internet 
tstepnony gateway service may often require searches 
lor Servers wnch provtde the cheapest cost for calling 
a specific destination. Database searches car be organ- 
ized for the) lund of query, but only if the broker knows 
that 4 wiM recede mostly or only these type of servce 
requests. 

Like a Server, the Broker muRicaets service an- 
nouncements if a Broker offers a service location for 
service X. men it «ui acvenrse itself as an offerng serv- 



ice X -broker. For example, a Broker offering a media 
server broker service may use a URL 

service: mediaserver-brokery/rnyrr«^ 

main.com:800 

5 Brokers themselves can have various attributes 
which define the broker service they provide. For exam- 
ple, this might be a typical attribute specification for an 
Internet telephony gateway broker: 
(NUMBER J3ATE WAY S=1 0C0). 
10 (AUTHENTicATlON=STRONG) 

This would cefine this telephony gateway broker as 
having a database of around 1000 gateways. The au- 
thentication attribute indicates that this broker provides 
strong assurances of the correctness of the gateway at* 
15 tributes it stores. 

Brokers can be additionally programmed to imple- 
ment some kind ot policy, local to the admmstrator of 
the Broker. This policy may restrict the set of Servers 
whose advertisements are kept by the particular Broker. 
20 For example, lets say a major ISP is running a broker 
service for telephony gateways for its customers. The 
ISP may decide that the Broker should reject ait internet 
telephony gateway service advertisements from Serv- 
ers run by a competing ISP. As another example, a Bro- 
2S ker may have limited disk space, and may drop adver- 
tisements for Servers which it believes are unekery to 
be used by any of its cierttsv based, say, on past history 
logs of service requests. It should be possible- for any 
sort of policy to be implemented However. Brokers 
30 should indicate the pokey attributes in their service ad- 
vertisement. 

The use of Brokers for a particular service also adds 
more scalability. Requests requiring attribute minimiza- 
tion can be considerably more CPU intensive than stm- 
35 pie look-ups. As the quenes for a particular service in- 
crease, and begr to exceed the processing capabilities 
of a Broker, additional Brokers can be added to distrib- 
ute the load. This load distribution can be implemented 
easily in the directory agent, to which Brokers are reg- 
<tf istered. The entire process becomes transparent to the 
clients and to the Servers. 

The main limitation to scalability tor the Brokers is 
the processing burden to search a large number of 
records. If the number of Servers for a particular service 
begins ;o exceed several tens of thousands, the storage 
requirements for them, and the time tor even a single 
search of the database for a match, can become exces- 
sive. In this scenario. Brokers always have the option of 
implementing some- kind of policy to restrict the size of 
so the database. As faster machines anc bigger asks be- 
come available, these policies can be lifted. Further- 
more, such restrictions open up the possibility of market 
competition for broker service. If a Broker ts writing to 
buy a big enough disk and fast enough machine to store 
5* and search every Server, that Broker can attract more 
customers to the broker service 

The use of Brokers aftows a client to find out about 
any particular service, once it can find a Broker tor thai 
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serves. Hew does a client find a broker tor a particular 
service'? To accomplish this, a Directory Agent (FIG. 1) 
may oe used. This device is like a Broker, it listens to a 
particular multicast address to find out services, and ft 
answers client queries for the services it knows about. 
However, it knows only about a very specific set of serv- 
ices 3roker services. This device is contacted first by a 
client to find out a Broker for a particular service. Gen- 
erally ;re client must know about its Directory Agent. It 
can seam in is information by DHCP manual configura- 
tion. or via the service location protocol. 

A client (FIG. 1 ). of course, ts a system which wants 
:o find the address of a Server wnich can provide some 
service oesired by the client. 

A Directory Agent can also function as a Broker and 
Tiairuatn a oata base listing available services. In this 
instance, the Directory Agent would provide service in- 
formation to a client without involving a Broker. Also, cf 
course u ts possible that a Directory Agent could pro- 
viae ^formation available from a Broker directly to a cli- 
ent without identifying any particular Broker. 

The final addition to the inventive architecture is a 
new device which we call a Notary. Its purpose is to less- 
en the burden of authentication which is placed on Bro- 
kers or to support non-multicast capable Servers. In- 
stead of registering directly with all the Brokers by mul- 
ticasting its advertisement, a Server wiB instead register 
with a Notary, it is the job of this Notary to provide some 
form at authentication (or the servers which it repre- 
sents Once authenticated, the Notary acts as a proxy 
:or these Servers, multicasting the advertisements for 
mem The 'orm of the service advertisements is nearly 
identical to that of a Server The exception is that all the 
autneni cation information m the message ts used to au- 
:nenttcate the Notary, and is the same for all Servers 
cemq advertised from this Notary. This lessens the bur- 
den ;i authentication to that of a single Notary, instead 
of many Servers. 

Due :o ooiitcal or technical problems regarding 
crypiograonc technologies, a unified strong authentica- 
tion nee nan ism may not be m place very soon. The use 
cf Notaries allows the servers to authenticate them- 
selves to the Notary oy any local or propnetary scheme. 

~. general, tor servces that nvolve biding authenti- 
:atton ot the Server may not be enougn. The user may 
want some assurance aoout the trustworthiness oi the 
-emote service operator Notary services could oe pro- 
ceed by authorities of sufficient influence and reputation 
:c oe trust eo by users. Such authorities may. for exanv 
oie. aotce mtsbehavmg service providers they repre- 
sent, usng non-eiectronc means (sucn as auortng ri- 
nancai records, ate. This kind of model already exists: 
creoit card companies wdl absorb the costs of fraudulent 
/encors ano revoke their capacities :o use the credit 
care :c cnarge customers 

Another requirement is for clients to know, at least 
'ougniy now distant a Server i$ it isdesiraoieforaoent 
'z '•auce seme *me of distance metric m a service re- 



quest to a Broker. 

To support this. Servers should include, m all serv- 
ice advertisements, an attnbute called INmALJTL. 
Thisartribute indicates the value of the TTL (Time tc live) 

5 field used n the IP packet containing the advertisement. 
When a Broker hears this advertisement on the multi- 
cast address, it notes the TTL in the IP oacKet when it 
arnved. and the value of the INITIALJTL. attnoute. 
From this, a Broker can ascertain the number of nops 

'0 from the server to itself. Similarly, when clients send a 
service request, they also include the INITIAL_TTL at- 
tribute h the request. When recerved at the Broner this 
allows the Broker to know how distant the client is from 
itself. 

15 In the service request, a client may optionally in- 
clude the DISTANCE attribute, anc specify any allowa- 
ble value for ft. A Broker can compute the attribute for 
each record, on a per client basis, by some kind of com- 
bination of the server-to-broker ana client-to-broker hop 

20 counts. The advantage o( this scheme is lhai tt does not 
require any sort of additional messages to compute dis- 
tance metrics. 

The flow chart in FiG. 2 describes the flow of events 
which occurs when the system is inrtiatized. it should be 

2$ noted that since the protocol ts executed by tnceoendent 
network entities, ti^&temcoral order of events may vary. 

What has been desenbed is the problem of location 
of sen/ices in the wxje area Internet. The proposed new 
architecture for resolving these drawbacks multicasting 

20 of registrations, sen/ice specific brokers, distance met- 
rics and hierarchical authentication services via nota- 
ries, solves the problems present in pnor an systems. 



1. A method for locating services in a wide area nter- 
net network, compnsng the steps of 

receiving a communication, from a Server X de- 
siring to provide a service A tc a client connect- 
ed to the internet. 

oenodcaily multicasting an advertisement for 
service A from Server X to a multicast grcuc 3, 
*** storing, m a Broker v*s dataoase the advertise- 

ment for service A muttcast oy Sen/er X. 
processing a request from client C to Broner y 
for a Server orovicmg service A. ana 
providing from Broker Y to client C an aodress 
so for Server X to octari Service A 

2. A metned for locaung servces m a wide area nter- 
net network in accorcancc with Claim : further in- 
cluding the steos of 

55 

periodically multeastmg trom Broner v an ad- 
vertisement for Service ^ervice-^-3rcner o 
multicast grouo G c 
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storing, in a Directory Agent Z*s database, the 
advertisement multicast by Broker Y 
processing a communication from client C who 
is seeking a Server for service A. and relaying 
said communication to Directory Agent Z. s 
initiating a database searcn by Directory Agent 
Z for providers of Service Service-A-Broker 
locating Broker Y sn response to saic database 
searcn and 

returning ar address for Broker Y to client C. r o 

A method for locating services in a wide area inte- 
rnet network in accordance with Claim 2. wherein 
said locating step further includes the steps of: 

is 

querying Broker Y on behatf of client C. and re- 
luming an address for Server X. provided by 
Broker Y. directly to client C. 

A method for locating services in a wide area inter- 20 
net network in accordance with Claim 1. further tn- 
ciuaing the steps of: 

registering, with a Notary, an advertisement 
generated by a Server. 2s 
providing, by the Notary, authentication for the 
Servers it represents, and 
mufticasting, by the Notary, the advertisements 
for the Servers registered with the Notary. 
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FIG. 2 



START: SERVES X (S TURNED ON. IT PROVIDES SERVICE A. (goto '.! 
i. SERVER X FORMULATES AN ADVERTISEMENT FOR SERVICE A AND 

MULTICASTS IT INTO MULTICAST GROUP G. FROM THEN ON SERVER 

X MULTICASTS ITS ADVERTISEMENT PERIODICALLY. ' (goto' 2) ' 
I. BROKER Y. WHICH OFFERS BROKER SERVICE FOR SERVICE a heaQc 

SERVER X's ADVERTISEMENT, ANO STORES IT IN ITS DATABASE 

(goto 3) 

3. BROKER Y SENOS AN ADVERTISEMENT FOR SERVICE A -BROKER 
AND MULTICASTS IT INTO A MULTICAST GROUP G2 IT WILL 
MULTICAST IT 'S A-BROKER SERVICE ANNOUNCEMENT PEHICOICAU V 
FROM THEN ON. (goto 4) 

4. DIRECTORY AGENT I HEARS THE A-3R0KER SERVICE 
ANNOUNCEMENT FROM Y. I* NOTES THAT Y PROVIDES A-BROKER 
SERVICE. ANO STORES THIS INFORMATION IN ITS DATABASE iocta 
5) 

5. CLIENT C WISHES TO :"IN0 A SERVER FOR SERVICE A. iaoto 5! 
5. CLIENT C CONTACTS DIRECTORY AGENT Z. ANO QUERIES IT FOR 

RECORDS OF BROKERS PROVIDING BROKER SERVICE FOR SERVICE a 
(goto 7) 

7. DIRECTORY AGENT 2 CHECKS ITS DATABASE. FINOS A MATCH FOR 
BROKER Y. ANO RETURNS Y's ADDRESS TO C (goto 8) 

8. CLIENT C CONTACTS Y. ANO ASKS FOR A SERVER PROVIDING 
SERVICE A. igo;o 9) 

9. BROKER Y CHECKS I"S OA \ ABASE. FINOS A MATCH IN SERVE. 3 Vi 
RECCRO. ANO RETURNS THE ADDRESS ANO CHARACTERISTICS ON X 
(goto :0) 

:0. CLIENT C CONTACTS SERVER X FOR SERVICE A. 
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